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Elliptic Curve Private Key Structure 
Abstract 
This document specifies the syntax and semantics for conveying 
Elliptic Curve (EC) private key information. The syntax and 
semantics defined herein are based on similar syntax and semantics 
defined by the Standards for Efficient Cryptography Group (SECG). 
Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 
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http://www.rfc-editor.org/info/rfc5915. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
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publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
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include Simplified BSD License text as described in Section 4.e of 
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described in the Simplified BSD License. 
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1. Introduction 


This document specifies a syntax and semantics for Elliptic Curve 
(EC) private key information. EC private key information includes a 
private key and parameters. Additionally, it may include the 
corresponding public key. The syntax and semantics defined herein 
are based on similar syntax and semantics defined by the Standards 
for Efficient Cryptography Group (SECG) [SECG1]. 


Most Public Key Infrastructures (PKIs) mandate local key generation; 
however, there are some PKIs that also support centralized key 
generation (e.g., the public-private key pair is generated by a 
Certification Authority). The structure defined in this document 
allows the entity that generates the private and public keys to 
distribute the key pair and the associated domain parameters. 


This syntax is useful when distributing EC private keys using 
PrivateKeyInfo, as defined in PKCS #8 [RFC5208]. Distributing an EC 
private key with PKCS#8 [RFC5208] involves including: 


a) id-ecPublickey, id-ecDH, or id-ecMQV (from [RFC5480]) with the 
namedCurve as the parameters in the privateKeyAlgorithm field; and 
b) ECPrivateKey in the PrivateKey field, which is an OCTET STRING. 


When an EC public key is included in the distributed PrivateKeylInfo, 
the publickKey field in ECPrivateKey is used. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. Elliptic Curve Private Key Format 
This section gives the syntax for an EC private key. 


Computationally, an EC private key is an unsigned integer, but for 
representation, EC private key information SHALL have ASN.1 type 


ECPrivateKey: 

ECPrivateKey ::= SEQUENCE { 
version INTEGER { ecPrivkeyVerl(1) } (ecPrivkeyVerl), 
privateKey OCTET STRING, 


parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, 
publicKkey [1] BIT STRING OPTIONAL 
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The fields of type ECPrivateKey have the following meanings: 


o version specifies the syntax version number of the elliptic curve 
private key structure. For this version of the document, it SHALL 
be set to ecPrivkeyVerl, which is of type INTEGER and whose value 
is one (1). 


Oo privateKey is the private key. It is an octet string of length 
ceiling (log2(n)/8) (where n is the order of the curve) obtained 
from the unsigned integer via the Integer-to-Octet-String-— 
Primitive (I20SP) defined in [RFC3447]. 


O parameters specifies the elliptic curve domain parameters 
associated to the private key. The type ECParameters is discussed 
in [RFC5480]. As specified in [RFC5480], only the namedCurve 
CHOICE is permitted. namedCurve is an object identifier that 
fully identifies the required values for a particular set of 
elliptic curve domain parameters. Though the ASN.1 indicates that 
the parameters field is OPTIONAL, implementations that conform to 
this document MUST always include the parameters field. 


Oo publicKey contains the elliptic curve public key associated with 
the private key in question. The format of the public key is 
specified in Section 2.2 of [RFC5480]. Though the ASN.1 indicates 
publicKey is OPTIONAL, implementations that conform to this 
document SHOULD always include the publicKey field. The publicKey 
field can be omitted when the public key has been distributed via 
another mechanism, which is beyond the scope of this document. 
Given the private key and the parameters, the public key can 
always be recomputed; this field exists as a convenience to the 
consumer. 


4. Other Considerations 


When generating a transfer encoding, generators SHOULD use 
Distinguished Encoding Rules (DER) [X.690] and receivers SHOULD be 
prepared to handle Basic Encoding Rules (BER) [X.690] and DER 
[X.690]. 


Section 1 described a format for transporting EC private keys (i.e., 
converting ECPrivateKey to PrivateKeyInfo [PKCS#8]); however, this 
format can also be used for local storage. 


Local storage of an unencrypted ECPrivateKey object is out of scope 
of this document. However, one popular format uses the .pem file 
extension. It is the PEM encoding, which is the Base64 encoding (see 
Section 4 of [RFC4648]), of the DER-encoded ECPrivateKey object that 
is sandwiched between: 
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Another local storage format uses the .der file extension. In this 
case, it is a DER [X.690] encoding of the ECPrivateKey object. 


Local storage of an encrypted ECPrivateKey object is out of scope of 
this document. However, ECPrivateKey should be the format for the 
plaintext key being encrypted. DER [X.690] encoding the ECPrivateKey 
will promote interoperability if the key is encrypted for transport 
to another party. PEM encoding the DER-encoded ECPrivateKey is 
common; "Proc-Type:" and "DEK-INFO:" fields [RFC1421] followed by the 
DER-encoded ECPrivateKey are sandwiched between: 


5. Security Considerations 


This structure does not protect the EC private key information in any 
way. This structure should be combined with a security protocol to 
protect it. 


Protection of the private key information is vital to public key 
cryptography. The consequences of disclosure depend on the purpose 
of the private key. If a private key is used for signature, then the 
disclosure allows unauthorized signing. If a private key is used for 
key management, then disclosure allows unauthorized parties to access 
the managed keying material. The encryption algorithm used in the 
encryption process must be as ’strong’ as the key it is protecting. 
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Appendix A. ASN.1 Module 
This appendix provides ASN.1 definitions for the structures described 
in this specification using ASN.1 as defined in [X.680], [X.681], 
[X.682], and [X.683] for compilers that support the 2002 ASN.1. 
ECPrivateKey { iso(1) identified-organization(3) dod(6) 
internet (1) security(5) mechanisms(5) pkix(7) id-mod(0) 
id-mod-ecprivateKey (65) } 
DEFINITIONS EXPLICIT TAGS ::= 
BEGIN 
-- EXPORTS ALL; 
IMPORTS 
—- FROM New PKIX ASN.1 [RFC5912] 
ECParameters, NamedCurve 
FROM PKIXAlgs-2009 
{ iso(1) identified-organization(3) dod(6) internet (1) 


security(5) mechanisms(5) pkix(7) id-mod (0) 
id-mod-pkixl-algorithms2008-02 (56) } 


A 


ECPrivateKey ::= SEQUENCE { 
version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), 
privateKey OCTET STRING, 


parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, 
publicKey [1] BIT STRING OPTIONAL 
} 


END 


Appendix B. Differences with SECG1 


This appendix lists the differences between this document and 
[SECG1]: 


1. This document uses the I20SP routine defined in [RFC3447] while 


SECG1 defines its own routine. The two routines result in the 
same output. 
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2. SECG1 constrains its parameters (i.e., the curves) to 
SECGCurveNames. This document constrains the parameters to 
NamedCurve from [RFC5480]. 


3. This document requires parameters be present while SECG1 does 
not. 
4. This document specifies requirements for encoding rules while 


SECG1 did not. 
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